From: kaf24@scramble.cl.cam.ac.uk Date: Wed, 23 Jun 2004 16:07:38 +0000 (+0000) Subject: bitkeeper revision 1.1008 (40d9aacaTruekKFS-caahQWxxfRQyQ) X-Git-Tag: archive/raspbian/4.8.0-1+rpi1~1^2~18113 X-Git-Url: https://dgit.raspbian.org/%22http:/www.example.com/cgi/%22https:/%22bookmarks:///%22http:/www.example.com/cgi/%22https:/%22bookmarks:/?a=commitdiff_plain;h=a164fb9945344fa8fd56cb70557796e119dbc729;p=xen.git bitkeeper revision 1.1008 (40d9aacaTruekKFS-caahQWxxfRQyQ) Remove done things from todo list. --- diff --git a/TODO b/TODO index 9ed217c11a..9d735bb6eb 100644 --- a/TODO +++ b/TODO @@ -48,22 +48,3 @@ page directory to a write-able page, we must ensure that no other CPU still has the page in its TLB to ensure memory system integrity. One other issue for supporting MP guests is that we'll need some sort of CPU gang scheduler, which will require some research. - -Currently, the privileged domain0 can request access to the underlying -hardware. This is how we enable the VGA console and Xserver to run in -domain0. We are planning on extending this functionality to enable -other device drivers for 'low performance' devices to be run in -domain0, and then virtualized to other domains by domain0. This will -enable random PCMCIA and USB devices to be used that we're unlikely to -ever get around to writing a Xen driver for. - -We'd also like to experiment moving the network and block device -drivers out of Xen, and each into their own special domains that are -given access to the specific set of h/w resources they need to -operate. This will provide some isolation against faulty device -drivers, potentially allowing them to be restarted on failure. There -may be more context switches incurred, but due to Xen's pipelined -asynchronous i/o interface we expect this overhead to be amortised. -This architecture would also allow device drivers to be easily -upgraded independent of Xen, which is necessary for our vision of Xen -as a next-gen BIOS replacement.